Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add support for path references #90

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

0xcaff
Copy link

@0xcaff 0xcaff commented Dec 8, 2024

This PR adds go to declaration for nix path references.

Screen.Recording.2024-12-07.at.8.00.34.PM.mov

I've kept it as simple as possible. It only supports stdpaths and not lookup paths. References are resolved following a simple set of rules.

fun resolvePath(fs: VirtualFileSystem, cwd: String, target: String): VirtualFile? {
val resolved = FileUtil.join(cwd, target)
val resolvedFile = fs.findFileByPath(resolved) ?: return null
if (resolvedFile.isDirectory) {
return resolvedFile.findChild("default.nix")
}
return resolvedFile
}

I spend hours a day reading nix files in IJ and this plugin is an important part of making this bearable. Thanks for making this, its really nice.

this is going to make my life suck significantly less

need to fix
* slurp up channel usages and flake inputs at index time and add as external library roots
* probably worthwhile to embed nix binaries into the ide plugin
file if first class primitive, directory is not
nix repl isn't in the ij sandbox path, avoid using it and instead do the path handling in band

this breaks handling of channel paths like <nixpkgs> but i don't care about those, would rather have something stable than something complete (also i only care about flakes)
Copy link
Contributor

@JojOatXGME JojOatXGME left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late reply. Looks mostly good. Here are some comments.

expr_std_path ::= PATH_SEGMENT (PATH_SEGMENT | antiquotation)* PATH_END
expr_std_path ::= PATH_SEGMENT (PATH_SEGMENT | antiquotation)* PATH_END {
mixin="org.nixos.idea.psi.impl.NixExprStdPathMixin"
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: Do you really need both, a reference contributor and the mixin? As far as I know, this are two different ways to implement references, you shouldn't need both.

Copy link
Author

@0xcaff 0xcaff Dec 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The mixin calls into the reference contributor here.

ReferenceProvidersRegistry.getReferencesFromProviders(this)

Seems like we don't need both but everyone uses the reference contributor + the mixin it seems. Without this explicit call the reference contributor will not work so I think you actually need both or can get away with only the mixin but not only the reference contributor.

import com.intellij.util.ProcessingContext
import org.nixos.idea.psi.impl.NixExprStdPathMixin

class NixFilePathReferenceContributor: PsiReferenceContributor() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (non-blocking): Would be nice to have some test to cover this functionality. However, not sure how a test could look like. I have some tests regarding references in SymbolNavigationTest, but their setup is probably far too complex for your use case, and it also doesn't support asserting for references to files.

It is not a hard requirement before I merge the PR, but it would be nice.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah i thought about this a bit and concluded idk how to write the tests. maybe we can pair on it together? i'm happy to schedule some time over the next few weeks if you're up for it.

Copy link
Contributor

@JojOatXGME JojOatXGME Dec 19, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean as a live call? I somehow didn't expect that in the context of a pull request on GitHub. 😄 Unfortunately, it is difficult for me to plan specific times before the start of January. Not sure if I want to wait for January. I suppose you are not on the 38C3 in Hamburg (Germany), are you?^^

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah! a live call! i prefer it as we can communicate a bit faster. seconds rtt instead of minutes / hours / days.

no plans to go to this 38C3 thing, seems interesting though maybe that could change, will see whether it makes sense.

what if we do this, let's merge the PR if you're fine with the lack of tests, let's get a time on the books (probably 30m) for early Jan and if i make it to 38C3 (unlikely though) we can meetup and solve it in real life? how does jan 1 sound (probably like after 5pm germany time?)

@0xcaff 0xcaff requested a review from JojOatXGME December 18, 2024 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants